Skip to content

Add converse actions & maintenance - #46

Open
ospaarmann wants to merge 16 commits into
devstopfix:mainfrom
layers-ai:improvements/add_converse_actions
Open

Add converse actions & maintenance#46
ospaarmann wants to merge 16 commits into
devstopfix:mainfrom
layers-ai:improvements/add_converse_actions

Conversation

@ospaarmann

Copy link
Copy Markdown

I added support for the actions Converse and ConverseStream since they offer a unified interface to interact with different models available on Bedrock and are the recommended way when using Tool Calling.

We recommend using the Converse API as it provides a consistent API, that works with all Amazon Bedrock models that support tool use.
Source

I also did some maintenance (bump dependency versions) and made sure all tests pass.

And I included the code from the PR that @holsee raised. I don't want to hijack your code, I just wanted to include your changes and your PR was open for a very long time. I hope this is ok. Maybe the maintainers can first merge your PR, since it is identical.

I hope someone sees this, since the library hasn't been active in some time.

Resources:

@devstopfix devstopfix self-assigned this Nov 26, 2025
@devstopfix

Copy link
Copy Markdown
Owner

Thanks for doing this @ospaarmann - we have been using the Converse API (in other BEAM language) and it's great.

ospaarmann and others added 5 commits August 19, 2026 11:33
…quest

On a non-200 response stream_objects!/3 raised ExAws.Error with only
"#{status}: #{reason}", discarding the response body and the
x-amzn-ErrorType header and leaking the hackney ref. Callers could not
tell throttling from capacity rejection from a permanent client error.

The non-200 path now drains headers and body (bounded receives), closes
the request, and raises ExAws.Bedrock.HttpError{status, error_type}
with a truncated body in the message. The stream's after_fun closes the
ref on abandoned enumeration. The 200 path is unchanged.

Callers rescuing ExAws.Error on the streaming path should add
ExAws.Bedrock.HttpError to their rescue list.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RGEBFJtBat8xazB73oHFjM
…mpty error type

Review findings: a byte-level cut at the body limit can split a
multibyte codepoint and make the exception message invalid UTF-8
(breaking JSON serialization of the very error report); drain was
per-receive bounded but not total-size bounded; malformed
x-amzn-errortype values normalized to "" instead of nil. Also names
HttpError in the stream_objects! doc.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RGEBFJtBat8xazB73oHFjM
The request fn and the Stream.resource next fn were anonymous closures
with receives nested five levels deep. open_stream/await_status handle
the request phase, next_event/await_event the streaming phase, each a
flat pattern match. No behavior change.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RGEBFJtBat8xazB73oHFjM
Satisfies Credo.Check.Readability.SinglePipe, which CI gates on.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RGEBFJtBat8xazB73oHFjM
Preserve status and error body on event stream failures, close the request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants